home *** CD-ROM | disk | FTP | other *** search
/ HyperLib 1997 Winter - Disc 1 / HYPERLIB-1997-Winter-CD1.ISO.7z / HYPERLIB-1997-Winter-CD1.ISO / オンラインウェア / UTIL / IIsi-RAM-Muncher フォルダ.sit / IIsi-RAM-Muncher フォルダ / About the RAM-Muncher < prev    next >
Text File  |  1994-05-11  |  4KB  |  102 lines
  1. IIsi RAM-Muncher INIT
  2. =====================
  3. Written by Paul Ripke <paul.p.r.ripke@bhp.bhpmel04.telememo.au>
  4.  
  5. An extension to speed up IIsi use without giving slow disk operation.
  6.  
  7. This extension is for Macintosh IIsi users, running System 7 or greater,
  8. only. The IIsi does not have VRAM, and video circuitry and the CPU must
  9. take turns to access the motherboard-mounted 1Mb that contains the screen
  10. image.
  11.  
  12. However, this screen image can only be up to around 330K, leaving 700 or
  13. so K for use by applications. Applications loaded into this space will be
  14. very slow, as they can only run when the CPU, and not the video circuitry,
  15. is accessing this bank of RAM.
  16.  
  17. A standard cure for this is to increase the size of the disk cache to 768K.
  18. This fills the rest of this bank, pushing the applications down into the
  19. other bank. The applications then execute at normal speed. However, a large
  20. disk cache is inefficient, as Apple's disk cacheing is somewhat less than
  21. optimal. And, as the cache only gets accessed by the CPU when the video
  22. is busy elsewhere, you have sped up your applications but slowed your hard
  23. disk.
  24.  
  25. Adding Macsbug means you can reduce the disk cache size to around 384K, but
  26. this is still not ideal. This extension marks the 1Mb not used by Macsbug or
  27. the screen as unused, so the disk cache lives in the other bank, and you can
  28. have a small, fast disk cache again.
  29.  
  30. The extension appeared as a posting in the comp.sys.mac.programmer newsgroup.
  31.  
  32. Here is the original post:
  33.  
  34. ----------
  35.  
  36. Article 89376 of comp.sys.mac.hardware:
  37. From: paul.p.r.ripke@bhp.bhpmel04.telememo.au (Paul Ripke)
  38. Newsgroups: comp.sys.mac.hardware
  39. Subject: Mac IIsi video and disk cache
  40. Date: Fri, 06 May 1994 10:28:10 +1000
  41. Organization: BHP IT
  42. Message-ID: <paul.p.r.ripke-060594102810@134.18.242.13>
  43. NNTP-Posting-Host: 134.18.242.13
  44. Mime-Version: 1.0
  45. Content-Type: text/plain; charset=ISO-8859-1
  46. Content-Transfer-Encoding: 8bit
  47.  
  48. In article <2pp2v6$f56@golden.kaleida.com>, Sayeed Ahmed <ahmedss@aol.com>
  49. wrote:
  50.  
  51. > I have a Mac II si which has four I meg SIMMS plus the one Meg that
  52. > is( I believe) on the motherboard.
  53. > It does not have a seperate Video Card.
  54. > 
  55. > The First question that I would like someone to answer
  56. > is Which memory bank is used for the Video here, and...
  57.  
  58. The video occupies the very top of the "topmost" bank, which happens to be
  59. the 1 meg soldered on the motherboard. As it only occupies about 330K, the
  60. rest of this bank is open for general use (including apps). This results in
  61. quite serious performance problems (personal experience). If you're
  62. interested, I wrote a small INIT which gobbles (most of) the remainder of
  63. that 1 Mb. I have 17 Mb to waste, so I'm not too worried there. It seems to
  64. run faster, but only when using in the "real world". Speedometer and other
  65. speed reporting programs show no change.
  66.  
  67. I have read resently that upping the disk cache (to about 384K) in the
  68. memory control panel increases performance, particularily vidoe
  69. performance. However I have found that the effects on disk performance
  70. amazing - ie slower than slow. This appears to be mainly due to memory
  71. contentions between cpu during writes and video, as the disk cache is in
  72. the same bank as video.
  73.  
  74. I have found that keeping the disk cache small with my INIT (see below)
  75. running is quite a good solution.
  76.  
  77. Now for my INIT. For those that are interested, here's the code:
  78.  
  79. main()
  80. {
  81.     unsigned long x;
  82.         
  83.     x = (unsigned long) BufPtr;
  84.     BufPtr = ((char *) ((x >> 20) << 20));
  85. }
  86.  
  87. What this does is to round BufPtr to the nearest Mb. It could be done with
  88. binary AND, but I got lazy :-)
  89.  
  90. I'm open to comments as to whether this really works, and if I should be
  91. coming a bit below the Mb boundary. I would love this code to run before
  92. the disk cache is allocated, and macsbug, and anything else, so that the
  93. top bank effectivly becomes VRAM, but I have found no way of doing this.
  94. Any ideas?
  95.  
  96. ----------
  97.  
  98. [For most users, having rarely-used Macsbug in the 1Mb is reasonable.
  99.  Only programmers debugging require the extra speed.]
  100.  
  101.  
  102.